How many people saw the IBM announcement that it has given up trying to fix the DXL string table memory leak problem?
I live in hope that DOORS version 10 will introduce support for an alternative main stream macro language that can free up string table space. DXL needs to be gracefully buried as it's beyond it's use-by date.
For those interested, have a look at http://www-01.ibm.com/support/docview.wss?uid=swg1PM10998&myns=swgrat&mynp=OCSSYQBZ&mync=E
Paul Miller
SystemAdmin - Thu Jun 17 19:33:06 EDT 2010 |
|
Re: DOORS string table memory leak problem cannot be fixed
llandale - Sun Jun 20 14:13:52 EDT 2010
I find it curious that there are various 'until' phrases in use: 'tied up until the DXL ends', 'tied up until the module closes', 'tied up until DOORS ends', and now 'tied up until the client is restarted'.
I also find it curious that there is a presumptuous movement that weak languages should be abandonded, despite all the code written in said languages. Perhaps yes there should be a BETTER language added, but no we should not junk pile the billions of lines of existing code.
|
|
Re: DOORS string table memory leak problem cannot be fixed
SystemAdmin - Mon Jun 21 03:29:29 EDT 2010 llandale - Sun Jun 20 14:13:52 EDT 2010
I find it curious that there are various 'until' phrases in use: 'tied up until the DXL ends', 'tied up until the module closes', 'tied up until DOORS ends', and now 'tied up until the client is restarted'.
I also find it curious that there is a presumptuous movement that weak languages should be abandonded, despite all the code written in said languages. Perhaps yes there should be a BETTER language added, but no we should not junk pile the billions of lines of existing code.
Perhaps I should have cast my words better - I certainly don't advocate the instant removal of DXL, that would cause a riot, but a graceful end of life over many years where DOORS can support multiple compilers. For example, the IBM tool ClearQuest supports both PERL and VBA scripting. Hopefully IBM will look at DOORS version 10 supporting DXL and JAVA or PERL (not VBA, it has memory leak problems as well).
Paul Miller
|
|
Re: DOORS string table memory leak problem cannot be fixed
jsarkic - Mon Jun 21 12:02:52 EDT 2010 SystemAdmin - Mon Jun 21 03:29:29 EDT 2010
Louie wrote "presumptuous movement that weak languages should be abandoned"
Perhaps I should have cast my words better - I certainly don't advocate the instant removal of DXL, that would cause a riot, but a graceful end of life over many years where DOORS can support multiple compilers. For example, the IBM tool ClearQuest supports both PERL and VBA scripting. Hopefully IBM will look at DOORS version 10 supporting DXL and JAVA or PERL (not VBA, it has memory leak problems as well).
Paul Miller
Hope nothing has changes during this year’s UGC.
|
|
Re: DOORS string table memory leak problem cannot be fixed
SystemAdmin - Tue Jun 22 08:18:01 EDT 2010
At the risk of speaking for IBM, I was just at this years conference and RW states:
"DXL continues to be an intergral part of DOORS future".
<OPINION>
The single largest code base at a customer is around 1.3 million lines. 40% of DOORS is written in DXL.
Here's what you will see; as DOORS and other tools are ported onto Jazz, you will be able to take advantage of OSLC representations of your requirements data. In this environment, you are free to use or write whatever floats your boat to get, put and manipulate stored information. New tools, even ones that work on DOORS specific data (DWA and RPE for example) do NOT use DXL, nor can they run user written DXL scripts from the client. They can, however be driven with Java Script or other techniques. The watchwords are "URL", and "OSLC".
</OPINION>
|
|